Previous Next Tracker index See it online !

(150/308) 1330 - XML plugin: Slow with large XML files

If you use Sidekick and the XML parser, then when a large XML file is edited, jEdit becomes very slow, even freezing, unless you turn off parsing in Sidekick first. For example, download and open the XML file at http://www.tellurianring.com/images/movies_list_data_1m.xml and hit Ctrl+End. On my system, jEdit will peg out at 50% CPU and remain frozen for a couple of minutes.
The problem goes away if in the Plugins options dlg, SideKick sxn, I turn off all three "Auto parsing Settings": "Parse on buffer switch", "Parse on buffer save", and "Parse on keystroke."
Be sure your folding mode set to "Sidekick" to reproduce this error.

Submitted	adblockfreak - 2010-06-15 21:54:02	Assigned	kerik-sf
Priority	5	Labels
Status	open	Group	None
Resolution	None

Comments

2010-06-15 21:55:23 adblockfreak	System info: OS: Windows XP Pro, Service Pack 2 Java: 1.6.0_18 according to the first test at http://www.javatester.org/version.html jEdit: 4.3.1 Sidekick 0.9 XML 2.6.1 XSLT 0.6.0
2010-12-08 23:44:06 ezust	- summary: Slow with large XML files --> XML plugin: Slow with large XML files
2010-12-08 23:44:06 ezust	Moving to plugin bugs tracker.
2011-06-16 18:04:34 kerik-sf	- assigned_to: nobody --> kerik-sf
2011-06-19 12:47:35 kerik-sf	progress has been made in r19545 and r19597. Now, SidekickTagHighlight is active by default : it uses Sidekick to locate the matching tag for matching tag highlight. Doing so reduces parsing a lot and loading movies_list_data_1m.xml and hitting Ctrl+End won't block for so long. It still takes a long time to parse these big files into a Sidekick tree and to create the corresponding UI (thousands of tree nodes). Another thing that speeds things up is to use the buffer's content directly (buffer.getSegment()) instead of making a copy (buffer.getText()). This is visible when moving the caret around near the end of movies_list_data_1m.xml to trigger matching tag highlight.